Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create router errors #3047

Merged
merged 3 commits into from
May 19, 2020
Merged

Create router errors #3047

merged 3 commits into from
May 19, 2020

Conversation

lmichelin
Copy link
Contributor

@lmichelin lmichelin commented Nov 30, 2019

This PR improves the way router errors are thrown.

4 router errors types have been created:

  • NavigationDuplicated
  • NavigationCancelled
  • NavigationRedirected
  • NavigationAborted

Before:

Uncaught (in promise) undefined

After:

Uncaught (in promise) Error: NavigationAborted: Navigating to location ("/foo?abort=y") has been aborted
    at eval (base.js:157)
    at eval (app.js:33)
    at iterator (base.js:153)
    at step (async.js:13)
    at step (async.js:17)
    at runQueue (async.js:21)
    at HashHistory.confirmTransition (base.js:179)
    at HashHistory.transitionTo (base.js:74)

@lmichelin
Copy link
Contributor Author

@posva I wrote some unit tests, the PR is ready to be reviewed 😉

@ariabuckles
Copy link

Bump on this? This would be really helpful for tracking down where promise rejections are coming from <3

@bponomarenko
Copy link

It seems this PR can also solve #3027. +1 for it to be merged and released.

@quentinus95
Copy link

quentinus95 commented Mar 17, 2020

@lmichelin could it be possible to export the exceptions so they can be imported (e.g. using import { NavigationDuplicated } from "vue-router")? It would allow catching the exceptions and use instanceof (especially when coding with TypeScript) to take decisions based on the thrown exceptions.

@posva
Copy link
Member

posva commented Mar 17, 2020

@quentinus95 instanceof with extended Errors doesn't work on some browsers like IE.
This PR is on hold until vuejs/router#123 is merged to make sure exported errors share the same naming and reduce migration cost

Copy link
Member

@posva posva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @lmichelin

Now that errors are stable on vue-router-next, I think we could try to align the user API part to make migration easier.
Namely, we need:

  • a type, from property
  • an object (to simulate the enumeration) with the same properties as NavigationFailureType
  • an exported TS interface so users can type errors

We can also remove:

It's okay to have a few differences like the lack of from and to properties. Also, let me know if you don't have the time so I can pick it up. If you only manage to add a few things but not all, that's, of course, fine as well!

Link to RFC: vuejs/rfcs#150
Link to vue-router-next errors file: https://github.com/vuejs/vue-router-next/blob/master/src/errors.ts

package.json Outdated Show resolved Hide resolved
src/history/abstract.js Outdated Show resolved Hide resolved
src/history/base.js Outdated Show resolved Hide resolved
src/history/errors.js Outdated Show resolved Hide resolved
src/history/errors.js Outdated Show resolved Hide resolved
src/history/errors.js Outdated Show resolved Hide resolved
Copy link
Member

@posva posva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realised you have a sample for an e2e test but it doesn't seem like you need it since you added a unit test already

src/util/warn.js Outdated Show resolved Hide resolved
src/history/base.js Show resolved Hide resolved
src/history/errors.js Outdated Show resolved Hide resolved
@lmichelin
Copy link
Contributor Author

I realised you have a sample for an e2e test but it doesn't seem like you need it since you added a unit test already

examples/router-errors/app.js is an example to show how to throw the errors, it's not made for e2e purposes, but just to show simple examples for these errors.

Copy link
Member

@posva posva left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for your help with this @lmichelin and sorry for the delay!

@posva posva merged commit 4c727f9 into vuejs:dev May 19, 2020
Copy link

@schmidtk schmidtk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good morning @lmichelin and @posva. I discovered this PR while handling navigation duplicated errors in my application and have been tracking the changes in case it requires migration when we update vue-router in the future.

I noted two places in the changes where NavigationFailureType.NAVIGATION_DUPLICATED references were not updated after the keys were changed in NavigationFailureType. I'm admittedly new to vue-router internals, so apologies if I misunderstood something here. Thanks for your time.

@@ -104,7 +110,7 @@ export class History {
// When the user navigates through history through back/forward buttons
// we do not want to throw the error. We only throw it if directly calling
// push/replace. That's why it's not included in isError
if (!isExtendedError(NavigationDuplicated, err) && isError(err)) {
if (!isRouterError(err, NavigationFailureType.NAVIGATION_DUPLICATED) && isError(err)) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be renamed to NavigationFailureType.duplicated.

@@ -51,7 +51,7 @@ export class AbstractHistory extends History {
this.updateRoute(route)
},
err => {
if (isExtendedError(NavigationDuplicated, err)) {
if (isRouterError(err, NavigationFailureType.NAVIGATION_DUPLICATED)) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here as well.

@lmichelin
Copy link
Contributor Author

You are right, I completely forgot these references 🙈

@lmichelin
Copy link
Contributor Author

I just opened a new PR to fix this: #3204

@alecgibson
Copy link

alecgibson commented May 29, 2020

I think this was a breaking change? We don't get the name property on the Error any more, which is useful when trying to handle particular errors (eg ignoring NavigationDuplicated). At the very least it may be nice to expose isRouterError as a utility method? And also to expose the failure types, especially because it's an opaque enum.

@posva
Copy link
Member

posva commented May 29, 2020

The errors were not documented and considered private. Checking navigation failures docs are on the way!

@alecgibson
Copy link

I'd say that checking an Error.name field is pretty standard practice, especially if it's not been prefixed with an underscore. I don't mind a change, but I'm just saying this could be considered breaking.

@snoozbuster
Copy link

snoozbuster commented Jun 10, 2020

+1 for this being a breaking change - once again I am back here to figure out why suddenly there are errors in my app where there weren't errors before (and the fact that it was merged and published without docs on how to do proper error checking also seems like a mistake)

@snoozbuster
Copy link

@posva - are these type constants exported from the package, so that I can inspect navigation errors in my application and handle them appropriately? I don't see anything which adds that, is it in another PR?

@afv
Copy link

afv commented Jun 16, 2020

I was checking err.name === 'NavigationDuplicated' before but after these changes the name is just 'Error'.

As a workaround I'm now importing NavigationFailureType at main.js and adding it to window:

import { NavigationFailureType } from 'vue-router/src/history/errors';

window.NavigationFailureType = NavigationFailureType;

On components I can now check err.type === window.NavigationFailureType.duplicated.

@posva
Copy link
Member

posva commented Jun 16, 2020

Please check #3220 for the proposed documentation for errors. Your feedback could be valuable there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants